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Abstract 


This document provides a problem statement, introduces terminology, 
and describes an extension for the base IETF emergency services 
architecture to address cases where an emergency caller is not 
authenticated, has no identifiable service provider, or has no 
remaining credit with which to pay for access to the network. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7406. 
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Les 


Introduction 


Summoning police, the fire department, or an ambulance in emergencies 
is one of the fundamental and most-valued functions of the telephone. 
As telephony functionality moves from circuit-switched telephony to 
Internet telephony, its users rightfully expect that this core 
functionality will continue to work at least as well as it has for 
the older technology. New devices and services are being made 
available that could be used to make a request for help; those 
devices are not traditional telephones, and users are increasingly 
expecting them to be able to place emergency calls. 


Roughly speaking, the IETF emergency services architecture (see 
[RFC6881] and [RFC6443]) divides responsibility for handling 
emergency calls among the access network (Internet Access Provider 


(IAP) or ISP); the application service provider (ASP), which may be a 
VoIP service provider (VSP); and the provider of emergency signaling 
services, the emergency service network (ESN). The access network 


may provide location information to end systems but does not have to 
provide any ASP signaling functionality. The emergency caller can 
reach the ESN either directly or through the ASP’s outbound proxy. 
Any of the three parties can provide the mapping from location to the 
Public Safety Answering Point (PSAP) URI by offering Location-to- 
Service Translation (LoST) [RFC5222] services. 


In general, a set of automated configuration mechanisms allows a 
device to function in a variety of architectures, without the user 
being aware of the details on who provides location, mapping 
services, or call-routing services. However, if emergency calling is 
to be supported when the calling device lacks access network 
authorization or does not have an ASP, one or more of the providers 
may need to provide additional services and functions. 


In all cases, the end device has to be able to perform a LoST lookup 
and otherwise conduct the emergency Call in the same manner as when 
the three exceptional conditions discussed below do not apply. 
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We distinguish among three conditions: 


No Access Authentication (NAA): In the NAA case, the emergency 
caller does not posses valid credentials for the access network. 
This includes the case where the access network allows 
pay-per-use, as is common for wireless hotspots, but there is 
insufficient time to enter credit card details and other 
registration information required for access. It also covers all 
cases where either no credentials are available at all or the 
available credentials do not work for the given IAP/ISP. As a 
result, the NAA case basically combines the No ASP (NASP) and 
zero-balance ASP (ZBP) cases below, but at the IAP/ISP level. 
Support for emergency call handling in the NAA case is subject to 
the local policy of the ISP. Such policy may vary substantially 
between ISPs and typically depends on external factors that are 
not under the ISP control. 


No ASP (NASP): The caller does not have an ASP at the time of the 
call. This can occur in case the caller either does not possess 
any valid subscription for a reachable ASP or does possess a valid 
subscription but none of the ASPs are reachable through the ISP. 


Note: The interoperability need is increased with this scenario 
Since the client software used by the emergency caller must be 
compatible with the protocols and extensions deployed by the ESN. 


Zero-balance ASP (ZBP): In the case of a zero-balance ASP, the ASP 
can authenticate the caller, but the caller is not authorized to 
use ASP services, e.g., because the contract has expired or the 
prepaid account for the customer has been depleted. 


These three cases are not mutually exclusive. A caller in need of 
help may, for example, be both in an NAA and NASP situation, as 
explained in more detail in Figure 1. Depending on local policy and 
regulations, it may not be possible to place emergency calls in the 
NAA case. Unless local regulations require user identification, it 
should always be possible to place calls in the NASP case, with 
minimal impact on the ISP. Unless the ESN requires that all calls 
traverse a known set of Voice Service Providers (VSPs), it is 
technically possible to let a caller place an emergency call in the 
ZBP case. We discuss each case in more detail in Section 3. 


Some of the functionality provided in this document is already 
available in the Public Switched Telephone Network (PSTN). 
Consequently, there is real-world experience available and not all of 
it is positive. For example, the functionality of calls without 
Subscriber Identity Modules (SIMs) in today's cellular system has 
lead to a fair amount of hoax or test calls in certain countries. 
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Biss 


This causes overload situations at PSAPs, which is considered harmful 
to the overall availability and reliability of emergency services. 


As an example, the Federal Office of Communications (OFCOM, 
Switzerland) provided statistics about emergency (112) calls in 
Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not 
offer SIM-less emergency calls except for almost a month in July 
2000 where a significant increase in hoax and test calls was 
reported. As a consequence, the functionality was disabled again. 
More details can be found in the panel presentations of the 3rd 
Standards Development Organization (SDO) Emergency Services 
Workshop [esw07]. 


Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in [RFC2119]. 


This document reuses terminology from [RFC5687] and [RFC5012], namely 
Internet Access Provider (IAP), Internet Service Provider (ISP), 
Application Service Provider (ASP), Voice Service Provider (VSP), 
Emergency Service Routing Proxy (ESRP), Public Safety Answering Point 
(PSAP), Location Configuration Server (LCS), (emergency) service dial 
string, and (emergency) service identifier. 


Use-Case Categories 


An end host needs to perform the following steps if it is not 
attached to the network and the user is starting to place an 
emergency call: 


Link-Layer Attachment: Some networks have added support for 
unauthenticated emergency access while others have advertised 
these capabilities using layer beacons (multicast or broadcast 


announcements). The end host learns about these unauthenticated 
emergency services capabilities from either the link layer type or 
advertisement. 


The end host uses the link-layer-specific network attachment 
procedures defined for unauthenticated network access in order to 
get access to the network. 
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When the link-layer network 


attachment procedure is completed, the end host learns basic 


configuration information using DHCP from the ISP. 
uses a Location Configuration Protocol 
Subsequently, 


information. 


The end host 
to retrieve location 
[RFC5222] is used to 


(LCP) 
the LoST protocol 


learn the relevant emergency numbers and to obtain the PSAP URI 


applicable for 
Emergency Call: 

emergency call 
Figure 1 compiles 


for requesting an 
between the three 


In case of the need for help, 
emergency number and the SIP User Agent 


that location. 


a user dials an 
(UA) initiates the 
procedures by communicating with the PSAP. 


the basic logic taking place during network entry 
emergency service and shows the interrelation 
conditions described earlier. 


Are credentials 
for network attachment 


| available? 
| 
NO V YES 
4---------------------------- * 
V V 
| Idle: Wait | [Execute | 
| for ES Call| |LLA Procedures | 
| Initiation | MS A i 
oeseri npin , | 
Is | T---------- 20 
emergency | | | Is ASP 
service | NO +----- Y | | configured? 
network +--->| End | | A E + 
attachment a / YES NO 
possible? 
v | v v 
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4------------ + | 4------------ + 4------------ + 
| Execute | | | Execute | | Execute | 
NAA =,- |-------- + Phone BCP NASP 
Procedures Procedures Procedures 
4------------— + +—------------ + do + 
Authorization for | | 
making an | | 
emergency call | | 
with the ASP/VSP? | | 
Fes sis E + v 
| NO | YES 4----- y 
| | | Done| 
M M NU SS / 
Hess de aA + 
| Execute | | Execute | 
ZBP Phone BCP 
Procedures Procedures 
4------------— $ +------------ + 
| | 
| | 
v v 
Focene Y d Y 
| Done| | Done| 
a / o / 
Abbreviations: 


LLA: Link-Layer Attachment 
ES: Emergency Services 


Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios 
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The diagrams below highlight the most important steps for the three 
cases. 


No 

credentials 

for network access 
available 


| Idle: Wait | 
| for ES Call| 
| Initiation | 


// IS -- 
/ emergency -- 
| service | NO Ho + 
Network  ./|------ >| Call 
attachment Failed 
N possible? / Neo ris / 


| Execute | 
| NAA | 
| Procedures | 
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Network 
attachment 
in progress 
v 
/--N Continue 
| | with 
| | application-layer 
\--/ interaction 


Figure 2: Flow Diagram: NAA Scenario 


===> + 
PSA O AR Start | ----------------- + 
Seis / | 
v v 
HS ==> + ERES FBSS + 
| NAA | | Regular | 
| Procedures | | Network Access | 
tas SSS Seas + | Procedures 
=== SPSS + 
| 
| | 
e a Or Q--------------------— 
| 
Network 
Attachment 
Completed 
| 
| 
M 
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4R------------ + 4R--------- * 
| ASP | NO | See | 
| Configured? |----- >| main | 
ASA TRAS + diagram 
| O / 
| 
| YES 
| 
v 
{=s 
/ == 
// == 
/ = q—e——————-— + 
| Authorization| YES | See | 
| for making | => en >| main | 
| ES call | | diagram | 
\ with / N / 
Y VSP/ASP? // 
NN / / 
\ // 
NT 
| wo 
| 
| 
v 
4R------------ + 
Execute 
ZBP 
| Procedures | 
4R------------ * 
| 
| call 


v 
deoseece-- + 
| cali | 

Success | 
Matias ates / 


Figure 3: Flow Diagram: ZBP Scenario 
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===> + 
ai Start | aii T 
oe / 
v v 
PSS ess tec + ==3===9=======2= + 
| NAA | | Regular | 
| Procedures | | Network Access | 
ELSA A + | Procedures 
4R---------------- * 
| 
| | 
Saa Q--------------------* 
| 
| 
| 
| 
Network 
Attachment 
Completed 
| 
v 
4R------------ * 4--------- * 
| ASP | YES | See | 
| Configured? | sten >| main | 
poranna + | diagram | 
| a / 
| 
| NO 
| 
v 
4R------------ * 
| Execute | 
| NASP | 
| Procedures | 
$ + 
| 
Call 


v 
quecccenc + 
| call | 
| Success | 
Msg / 


Figure 4: Flow Diagram: NASP Scenario 
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The NAA procedures are described in Section 6. The ZBP procedures 
are described in Section 4. The NASP procedures are described in 
Section 5. The Phone BCP procedures are described in [RFC6881]. The 
LLA procedures are not described in this document since they are 
Specific to the link-layer technology in use. 


4. ZBP Considerations 


ZBP includes all cases where a subscriber is known to an ASP but 
lacks the necessary authorization to access regular ASP services. 
Example ZBP cases include empty prepaid accounts, barred accounts, 
roaming and mobility restrictions, or any other conditions set by ASP 
policy. 


Local regulation might demand that emergency calls cannot proceed 


without successful service authorization. In some regulatory 
regimes, however, it may be possible to allow emergency calls to 
continue despite authorization failures. To distinguish an emergency 


call from a regular call, an ASP can identify emergency sessions by 
inspecting the service URN [RFC5031] used in call setup. The ZBP 
case, therefore, only affects the ASP. 


Permitting a call despite authorization failures could present an 


opportunity for abuse. The ASP may choose to verify the destination 
of the emergency calls and to only permit calls to certain, 
preconfigured entities (e.g., to local PSAPs). Section 7 discusses 


this topic in more detail. 


An ASP without a regulatory requirement to authorize emergency calls 
can deny emergency call setup. Where an ASP does not authorize an 
emergency call, the caller may be able to fall back to NASP 
procedures. 


5. NASP Considerations 


To start the description, we consider the sequence of steps that are 
executed in an emergency call based on Figure 5. 


o As an initial step, the devices attach to the network as shown in 
step (1). This step is outside the scope of this section. 


o When the link-layer network attachment procedure is completed, the 


end host learns basic IP configuration information using DHCP from 
the ISP, as shown in step (2). 
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o When the end host has configured the IP address, it starts an 
interaction with the discovered LCS at the ISP, as shown in step 
(3). In certain deployments, the ISP may need to interact with 
the IAP. This protocol exchange is shown in step (4). 


o Once location information is obtained, the end host triggers the 
LoST protocol to obtain the address of the ESRP/PSAP. This is 
shown in step (5). 


o In step (6), the SIP UA initiates a SIP INVITE request towards the 
indicated ESRP. The INVITE message contains all the necessary 
parameters required by Section 5.1.5. 


o The ESRP receives the INVITE and processes it according to the 
description in Section 5.3.3. 


o The ESRP routes the call to the PSAP, as shown in step (8), 
potentially interacting with a LoST server first to determine the 
route. 


o The PSAP evaluates the initial INVITE and aims to complete the 
call setup. 


o Finally, when the call setup is completed, media traffic can be 
exchanged between the PSAP and the SIP UA. 


For brevity, the end-to-end SIP and media exchange between the PSAP 
and SIP UA are not shown in Figure 5. 
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+------- + 
| PSAP | 
| | 
+------- + 
| (8) 
+---------- +(7) +---------- + 
LoST <-->] ESRP 
Server 
+---------- + +---------- + 
4---------------- 4---------------- | -------------- + 
| ISP | | | 
|+---------- + | | + 
LCS-ISP (3) DHCP 
<-+ Server 
[+---------- + | | | +---------- d 
4------- ^------ 4-—4R---------------- | ----------- A+ 
4------- |------ 4-4---------------- | ----------- |--+ 
| tap | (4) | ‘| 5) | ud 
V 
p---------- t 
|| LCS-IAP | | +-------- + | | 
|| | | | Link- | (6) | 
|+---------- + | | | Layer | | | 
| | | Device | (2) | 
I a | 
| | | | | | | 
+-------------- +-|------- |-------- |----------- |--+ 
| | | | | 
| (1) | | | 
| ' 4 32s 
| | v | 
| | _+---------- + | 
| +->| End | <------------- + 
*  »| Host | 
+---------- + 
Figure 5: Architectural Overview 
Note: Figure 5 does not indicate who operates the ESRP and the LoST 
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5.1.  End-Host Profile 
5.1.1.  LoST Server Discovery 


The end host MUST discover a LoST server [RFC5222] using DHCP 
[RFC5223] unless a LoST server has been provisioned using other 
means. 


5.1.2.  ESRP Discovery 


The end host MUST discover the ESRP using the LoST protocol [RFC5222] 
unless a ESRP has been provisioned using other means. 


5.1.3. Location Determination and Location Configuration 


The end host MUST support location acquisition and the LCPs described 
in Section 6.5 of [RFC6881]. The description in Sections 6.5 and 6.6 
of [RFC6881] regarding the interaction between the device and the 
Location Information Server (LIS) applies to this document. 


The SIP UA in the end host MUST attach available location information 
in a Presence Information Data Format Location Object (PIDF-LO) 
[RFC4119] when making an emergency call. When constructing the 
PIDF-LO, the guidelines in the PIDF-LO profile [RFC5491] MUST be 
followed. For civic location information, the format defined in 
[RFC5139] MUST be supported. 


5.1.4. Emergency Call Identification 
To determine which calls are emergency calls, some entity needs to 
map a user-entered dial string into this URN scheme. A user may 
"dial" 1-1-2, 9-1-1, etc., but the call would be sent to 
urn:service:sos. This mapping SHOULD be performed at the endpoint 


device. 


End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 
as emergency calls for their home emergency dial string. 


5.1.5. SIP Emergency Call Signaling 
SIP signaling capabilities [RFC3261] are REQUIRED for end hosts. 
The initial SIP signaling method is an INVITE. The SIP INVITE 
request MUST be constructed according to the requirements in 


Section 9.2 of [RFC6881]. 


To enable callbacks, SIP UAs SHOULD place a globally routable URI in 
a Contact header field. 
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5.1.6. Media 


Endpoints MUST comply with the media requirements for endpoints 
placing an emergency call as described in Section 14 of [RFC6881]. 


5.1.7. Testing 


The description in Section 15 of [RFC6881] is fully applicable to 
this document. 


5.2.  IAP/ISP Profile 
5.2.1.  ESRP Discovery 


An ISP MUST provision a DHCP server with information about LoST 
servers [RFC5223]. An ISP operator may choose to deploy a LoST 
Server or to outsource it to other parties. 


5.2.2. Location Determination and Location Configuration 


The ISP is responsible for location determination and exposes this 
information to the endpoints via location configuration protocols. 
The considerations described in [RFC6444] are applicable to this 
document. 


The ISP MUST support one of the LCPs described in Section 6.5 of 
[RFC6881]. The description in Sections 6.5 and 6.6 of [RFC6881] 
regarding the interaction between the end device and the LIS applies 
to this document. 


The interaction between the LIS at the ISP and the IAP is often 
proprietary, but the description in [LIS] may be relevant to the 
reader. 

5.3.  ESRP Profile 

5.3.1. Emergency Call Routing 
The ESRP continues to route the emergency call to the PSAP 
responsible for the physical location of the end host. This may 
require further interactions with LoST servers but depends on the 
Specific deployment. 


5.3.2. Emergency Call Identification 


The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 
the 'urn:service:sos' tree). 
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5.3.3. SIP Emergency Call Signaling 


SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The 
ESRP MUST process the messages sent by the client, according to 
Section 5.1.5. 


Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT 
restrict incoming calls to a particular set of ASPs. 


6. Lower-Layer Considerations for NAA Case 


Some networks have added support for unauthenticated emergency access 
while others have advertised these capabilities using layer beacons. 
The end host learns about these unauthenticated emergency services 
capabilities either from the link-layer type or from advertisement. 


It is important to highlight that the NAA case is inherently a Layer 
2 problem, and the general form of the solution is to provide an 
"emergency only" access type, with appropriate limits or monitoring 
to prevent abuse. The described mechanisms are informative in nature 
Since the relationship to the IETF emergency services architecture is 
only indirect, namely via some protocols developed within the IETF 
(e.g., EAP and EAP methods) that require extensions to support this 
functionality. 


This section discusses different methods to indicate an emergency 
Service request as part of network attachment. It provides some 
general considerations and recommendations that are not specific to 
the access technology. 


To perform network attachment and get access to the resources 
provided by an IAP/ISP, the end host uses access technology-specific 
network attachment procedures, including, for example, network 
detection and selection, authentication, and authorization. For 
initial network attachment of an emergency service requester, the 
method of how the emergency indication is given to the IAP/ISP is 
Specific to the access technology. However, a number of general 
approaches can be identified: 


Link-layer emergency indication: The end host provides an 
indication, e.g., an emergency parameter or flag, as part of the 
link-layer signaling for initial network attachment. Examples 
include an emergency bit signaled in the IEEE 802.16-2009 wireless 
link. In IEEE 802.11 WLAN [IEEE802.11], an emergency support 
indicator allows the station (i.e., end host in this context) to 
download before association to a Network Access Identifier (NAI), 
which it can use to request server-side authentication only for an 
IEEE 802.1X network. 
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Higher-layer emergency indication: Typically, emergency indication 
is provided in the network access authentication procedure. The 
emergency caller's end host provides an indication as part of the 
access authentication exchanges. Authentication via the EAP 
[RFC3748] is of particular relevance here. Examples are the EAP 
NAI decoration used in Worldwide Interoperability for Microwave 
Access (WiMAX) networks and modification of the authentication 
exchange in IEEE 802.11 [nwgstg3]. 


6.1. Link-Layer Emergency Indication 


In general, link-layer emergency indications provide good integration 
into the actual network access procedure regarding the enabling of 
means to recognize and prioritize an emergency service request from 
an end host at a very early stage of the network attachment 
procedure. However, support in end hosts for such methods cannot be 
considered to be commonly available. 


No general recommendations are given in the scope of this memo due to 
the following reasons: 


o Dependency on the specific access technology. 


o Dependency on the specific access network architecture. Access 
authorization and policy decisions typically happen at different 
layers of the protocol stack and in different entities than those 
terminating the link-layer signaling. As a result, link-layer 
indications need to be distributed and translated between the 
different protocol layers and entities involved. Appropriate 
methods are specific to the actual architecture of the IAP/ISP 
network. 


o An advantage of combining emergency indications with the actual 
network attachment procedure performing authentication and 
authorization is the fact that the emergency indication can 
directly be taken into account in the authentication and 
authorization server that owns the policy for granting access to 
the network resources. As a result, there is no direct dependency 
on the access network architecture that otherwise would need to 
take care of merging link-layer indications into the 
authentication, authorization, and policy decision process. 


o EAP signaling happens at a relatively early stage of network 


attachment, so it is likely to match most requirements for 
prioritization of emergency signaling. However, it does not cover 
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early stages of link-layer activity in the network attachment 
process. Possible conflicts may arise, e.g., in case of filtering 
based on Media Access Control (MAC) in entities terminating link- 
layer signaling in the network (like a base station). In normal 
operation, EAP-related information will only be recognized in the 
Network Access Server (NAS). Any entity residing between the end 
host and NAS should not be expected to understand/parse EAP 
messages. 


o An emergency indication can be given by forming a specific NAI 
that is used as the identity in EAP-based authentication for 
network entry. 


6.2. Securing Network Attachment in NAA Cases 


For network attachment in NAA cases, it may make sense to secure the 
link-layer connection between the device and the IAP/ISP. This 
especially holds for wireless access with examples being access based 
on IEEE 802.11 or IEEE 802.16. The latter even mandates secured 
communication across the wireless link for all IAP/ISP networks based 
on [nwgstg3]. 


Therefore, for network attachment that is by default based on EAP 
authentication, it is desirable also for NAA network attachment to 
use a key-generating EAP method (that provides a Master Session Key 
(MSK) to the authenticator to bootstrap further key derivation for 
protecting the wireless link). 


To match the above, the following approaches can be identified: 
1) Server-Only Authentication: 


The device of the emergency service requester performs an EAP 
method with the IAP/ISP EAP server that performs server-side 
authentication only. An example for this is EAP-TLS [RFC5216]. 
This provides a certain level of assurance about the IAP/ISP to 
the device user. It requires the device to be provisioned with 
appropriate trusted root certificates to be able to verify the 
server certificate of the EAP server (unless this step is 
explicitly skipped in the device in case of an emergency service 
request). This method is used to provide access of devices 
without existing credentials to an IEEE 802.1X network. The 
details are incorporated in the IEEE 802.11-2012 specification 
[IEEE802.11]. 
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2) Null Authentication: 


In one case (e.g., WiMAX), an EAP method is performed. However, 
no credentials specific to either the server or the device or 
subscription are used as part of the authentication exchange. An 
example for this would be an EAP-TLS exchange using the 
TLS DH anon (anonymous) ciphersuite. Alternatively, a publicly 
available static key for emergency access could be used. In the 
latter case, the device would need to be provisioned with the 
appropriate emergency key for the IAP/ISP in advance. In another 
case (e.g., IEEE 802.11), no EAP method is used, so that empty 
frames are transported during the over-the-air IEEE 802.1X 
exchange. In this case, the authentication state machine 
completes with no cryptographic keys being exchanged. 


3) Device Authentication: 


This case extends the server-only authentication case. If the 
device is configured with a device certificate and the IAP/ISP EAP 
server can rely on a trusted root allowing the EAP server to 
verify the device certificate, at least the device identity (e.g., 
the MAC address) can be authenticated by the IAP/ISP in NAA cases. 
An example for this is WiMAX devices that are shipped with device 
certificates issued under the global WiMAX device public-key 
infrastructure. To perform unauthenticated emergency calls, if 
allowed by the IAP/ISP, such devices perform network attachment 
based on EAP-TLS with client authentication based on the device 
certificate. 


7. Security Considerations 


The security threats discussed in [RFC5069] are applicable to this 
document. 


The NASP and NAA cases introduce new vulnerabilities since the PSAP 
operator will typically not have any information about the identity 
of the caller via the signaling path. Today, in countries where this 
functionality is used for Global System for Mobile Communications 
(GSM) networks, this has lead to a significant amount of misuse. 


In the context of NAA, the IAP and the ISP will probably want to make 
sure that the claimed emergency caller indeed performs an emergency 
call rather than using the network for other purposes, and thereby 
acting fraudulent by skipping any authentication, authorization, and 
accounting procedures. By restricting access of the unauthenticated 
emergency caller to the LoST server and the PSAP URI, traffic can be 
restricted only to emergency calls. This can be accomplished with 
traffic separation. However, the details, e.g., for using filtering, 
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8. 


8. 


depend on the deployed ISP architecture and are beyond the scope of 
this document. 


We only illustrate a possible model. If the ISP runs its own 
(caching) LoST server, the ISP would maintain an access control list 
populated with IP-address information obtained from LoST responses 
(in the mappings). These URIs would either be URIs for contacting 
further LoST servers or PSAP URIs. It may be necessary to translate 
domain names returned in LoST responses to IP addresses. Since the 
media destination addresses are not predictable, the ISP also has to 
provide a SIP outbound proxy so that it can determine the media 
addresses and add those to the filter list. 


For the ZBP case, the additional aspect of fraud has to be 
considered. Unless the emergency call traverses a PSTN gateway or 
the ASP charges for IP-to-IP calls, there is little potential for 
fraud. If the ASP also operates the LoST server, the outbound proxy 
MAY restrict outbound calls to the SIP URIs returned by the LosT 
server. It is NOT RECOMMENDED to rely on a fixed list of SIP URIs, 
as that list may change. 


RFC 6280 [RFC6280] discusses security vulnerabilities that are caused 
by an adversary faking location information and thereby lying about 
the actual location of the emergency caller. These threats may be 
less problematic in the context of an unauthenticated emergency when 
location information can be verified by the ISP to fall within a 
specific geographical area. 
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